@marcinkuzminski if you can, please fix problem with gzip not having contextmanager in older pythons. Otherwise I'll fix that tomorrow.

So, there is still documentation missing. After adding it we can probably merge this

I have few comments:

• i don't like the fact that both lockfile and cache puts their files in the workdir, making it dirty after that
• how are the cases of starting >1 repo simultaneously handled with the lockfile ?
• what happens if the lock is not released (eg. you kill vcs before cache is made, i think it leaves the lockfile)

i'm asking so maybe you know the answer now, else we need to test that

1. This is initial idea. It's simply to ignore those files as we do with so many others. The problem with having those outside of the repository is: how we would identify different repositories with same names?
2. Well, dogpile effect problem has to be checked indeed.
3. It's not cleared when the process is killed unfortunately. But I guess it's external application problem to make sure locks are cleared. We can also add timeout and raise exception if it take too long to acquire a lock.

The other thing is that we haven't actually check the performance improvement. For relatively small repositories (~5k commits) the difference is very small. For repository with 20k commits the difference is significant (almost twice as fast). Haven't tried with larger repos.

re1. i mean on each repo i run this it make the workdir dirty, i think simple enought would be to store those files inside .hg dir for Mercurial or .git dir for Git (unless it's a bare repo, then at top level

re3 - we could switch to pid-lock it's basically storing the PID inside lock file, if lockfile is there, but pid is not, lock is obsolete and get's rewritten

twice fast for 20K commit repo sounds nice !